Fivetran：云计算时代的数据管道，估值56亿美金的行业创新者

积极推动中国企业家参与科技大航海

打造全球领先的资产配置服务

本研究来自海外独角兽共创者投稿

作者：穆奕

编辑：penny，lavida

排版：雨欣

作者介绍

穆奕，前开源基础软件公司资深研发和国内商业化华南区域业务负责人，对规模化增长、各行各业的数字化，削减信息获取壁垒，计算机科学在跨学科的融合等融合型创新充满兴趣。

如果数据是新石油， Fivetran 就是从源头到炼油厂的管道。

在信息爆炸的时代，为了应对不断变化的业务需求，企业通常会选用至少两种数据库：一种负责业务的联机交易数据库（比如 Oracle），一种负责数据分析的数据仓库（比如 Greenplumn、Hadoop、云上的 Snowflake）。两种数据库之前的数据同步是通过复杂、高度定制的 ETL （后文会详细介绍）管道来解决的，数据管道需要不断维护，复杂度极高。

Fivetran 就是要在传统 ETL 的基础上进行创新。这是一家领先的数据整合公司，成立于 2012年。Fivetran 想解决的问题看似简单，做起来很复杂：成为将数据从源头连接到仓库的管道，并为用户解决和隐蔽中间一切复杂的处理过程。

Fivetran 可以连接企业的关键数据源，提取和处理所有数据，然后将其转储到数据仓库（如 Snowflake、BigQuery 或 RedShift），以便在需要时进行 SQL 访问和进一步转换。“Fivetran有一个独特的使命：让用户使用数据就像用电一样简单，无论数据的来源如何。”

2020 年，Fivetran 的客户和收入双双翻倍。2021 年，完成 a16z 领投的 D 轮融资，估值达 56 亿美元，并借此完成了对云下数据整合公司 HVR 的收购。这次收购极大地加强了 Fivetran 在数据整合赛道的领导者地位。Fivetran的CEO George Fraser 表示，收购 HVR 后，Fivetran 的年收入将超过 1 亿美元。

Fivetran 支持数百个数据库的连接，如 IBM、SAP、Oracle 和 Snowflake。目前，全球已有超过 750 家公司，包括 ASICS、Autodesk、DocuSign、Forever 21、WeWork 和 Urban Outfitters 等知名企业与 Fivetran 合作。

本文将从数据整合工具赛道的特点出发，通过回顾 Fivetran 的创新和历史，尝试回答 Fivetran 为什么在这个古老的赛道还能玩出新花样，并探讨 Fivetran 在竞争中的未来。

以下为本文目录，建议结合下方要点进行针对性阅读。

👇

01. Fivetran 创新背后的机会

• 什么是 ETL？

• 云是最大的推手

02. Fivetran 的模式：ELT + E 而不是传统的 ETL

• Fivetran 的产品线与特点

03. 发展策略：云上数据库的连接器

• 不仅数据整合，更发现数据的价值

• 边际递减的定价策略

• 补完最后一块拼图：并购 HVR

04. 领导者面对的挑战

• 同为初创企业的挑战

• 古老、新兴又充满竞争的赛道

01.

Fivetran 创新背后的机会

George Fraser（左）    Taylor Brown（右）

从 CMU 本科毕业的 George Fraser（左），拥有计算机和生物双学位，毕业后没有加入互联网公司，而是去匹兹堡大学学习神经生物学。博士毕业后，George 在一家运营虚拟生物实验室的公司做科学家。

或许受到当时美国云计算蓬勃发展的感召，George 从 Emerald Cloud Lab 离开后，和自己儿时的发小 Taylor Brown（右）一起创立了 Fivetran 。最初，Fivetran 主打的业务场景是帮企业把数据搬上云上数仓，如今 Fivetran 估值已经超过 50 亿美元，愿景是让所有企业像用电一样使用数据。

在了解 Fivetran 具体如何解决问题前，我们需要先了解它所处的行业背景。

数据整合工具这个赛道跟关系型数据库赛道（以 Oracle 为代表）的历史一样长。 从数据库被发明，且在各大企业被大规模使用起，数据整合工具赛道也应运而生，Oracle 也是因为收购了 Golden Gate（基于日志的结构化数据复制软件） 才补上了自己的一块拼图，在和 IBM DB2（IBM 开发的一套关系型数据库管理系统）的竞争中获得优势。

Fivetran 之所以能够在这个古老的赛道进行创新，最主要的原因有两点：一是传统 ETL 以前受限于硬件成本，有许多可改进之处；二是云计算的发展让企业对数据量的使用大幅增加，下面我们会分别探讨。

什么是 ETL？

ETL  是一种在数据整合领域的标准方法论，是三个重要操作：Extract（提取），Transform（转换），Load（加载）的简称。ETL 最早可追溯到 20 世纪 70 年代，截止现在，也仍然在各大小公司中被普遍使用，以至于“ETL”几乎成了数据整合赛道的代名词。

在 ETL 定义中，数据管道从源头（可能是应用、数据库、文件、事件）提取数据，将数据按照一定的数据模型进行转换（更方便后续分析），之后将数据加载进入数据局仓库中，以供分析师进行分析，或为后续的报告和仪表盘做好准备工作。

上面是一个“传统 ETL 操作”的示意图，可以看到数据转换这个环节，被放在数据抽取和数据加载之间，这是为了在硬件成本和计算效率中达到平衡：

 一方面，对源数据进行汇总或总结，可以降低在数据仓库阶段的计算时间，提升效率，毕竟数据量越小，计算效率越高；

另外一方面也可以在数据转换阶段更有效的利用资源，毕竟当时的硬件资源还是非常昂贵的。

某种意义上讲， ETL 在设计时受到了存储、计算、网络带宽等硬件条件的约束。昂贵的计算资源需要在流程中的每个阶段都能被利用上。回看 1970s，集成电路作为第三代计算机也才刚刚进入生产线上生产，NVME SSD、DDR3 这样的高速磁盘和内存协议还不知道在哪儿。

任何软件或流程的设计都与当时的硬件条件有不可割裂的关系，如果把软件比做摩天大楼，那么硬件则是这座大楼的地基，地基的好坏直接影响了大楼的设计上限。这种设计，可以在数据转换过程中高效利用存储、计算和带宽资源来处理数据，通过计算的前置尽可能削减后续 BI 工具和数据仓库中处理数据时所花费的时间。

ETL 构建流程

除了抽取、转换、加载三个大的阶段外，从一个工程师的视角看，构建一个 ETL 的典型流程通常包括：

1. 数据从哪来

2. 确定项目所要的数据范围（比如 2019 年到 2021 年的数据，再比如只需要员工的年龄信息）

3. 定义分析员和其他终端用户需要的数据模型/模式

4. 建立数据管道，包括提取、转换和加载功能

5. 进行分析工作并提取洞察力

由于在 ETL 中，提取和转换都是在数据被加载到目的地之前进行的，它们是紧耦合的。此外，由于转换是由分析师或业务部门的具体需求决定的，因此：

• 每条 ETL 管道都是一个复杂的、定制的解决方案。

• 这些管道的定制性质使得扩展非常困难，特别是增加新的数据源和更改数据模型的逻辑。

在前几十年，硬件昂贵，而工程师资源相对低廉，因此每当企业遇到新需求时，只能选择重新构造一个ETL 管道，这是敏捷性极差的工作模型。

此外，提取和转换之间的紧密耦合意味着，如果转换出现问题，数据整合的管道也会停止，数据不会进入数据仓库，从而造成 BI 仪表盘中的数据持续落后。也就是说，任何使用 ETL 工具来做数据整合（Data Integration）的公司都会面临以下挑战：

• 劳动密集型和衍生的费用：因为系统运行在定制的代码库上，需要一个专门的数据工程师团队来构建和维护。

• 持续的维护成本：由于数据管道既提取又转换数据，一旦上游模式改变或下游数据模型改变，管道就会中断，需要对 ETL 软件的代码库进行广泛的修改。

• 自定义和复杂性：数据管道不仅提取数据，而且根据终端用户的具体分析需求进行复杂的转换。这意味着大量的定制代码。

这些挑战在云时代会进一步被放大，因为在云上构建 SaaS 服务的创业公司，产品越来越多，同时硬件性能的进步也使得原本 ETL 的设计出现了非常大的局限。要知道，任何一个不断提高数据素养（Data Literacy）的企业都有两个常见的需求：

• 上游数据源的变更（数据源发生变化）

• 下游分析需求的变化（数据模型的逻辑发生变化）

这都对 ETL 工具提出了新的要求，需要它极度灵活、极度易用、极度高效。回到 2012 年，Fivetran 的两位创始人结合现存 ETL 工具的现状和对未来的云上业务的发展，有着这样的观察和判断：

“企业将会在云上构建越来越多的业务，不仅包括数据库，还包括 SaaS 服务，而传统的 ETL 在未来将不堪重负。复杂笨重的配置会让传统 ETL 越来越无法满足未来云上数据的使用需求。”

基于这样的考虑，他们通过 YC 孵化了自己的项目，并致力于在云上通过 SaaS 服务（ELT 而不是 ETL）的方式将不同源头的数据汇聚到云上的数据仓库，比如 Snowflake、AWS RedShit 等。值得一提的是，自从创立之始，Fivetran 一直就是 Snowflake 资深的合作伙伴。和 Snowflake 几乎同时创立的它，也陪着 Snowflake 一起见证了诸多历史时刻。

说完了什么是 ELT，接下来我们看看 Fivetran 能够实现创新的最大变量是什么：一方面，是因为硬件成本的变化导致 ETL 需要新的改变，另一方面是因为企业上云。当然，这两个变量是紧密联系在一起的。

云是最大的推手

云成为基础设施，让很多企业的业务形态发生了变化。企业总是希望处理更多数据，因为更多数据会带来更多的洞察和更大的差异化，真正可以作为第五种生产要素参与到公司的生产、运营中。

目前来看，仓储、分析、流媒体、可视化等业务都是企业中增长最快的部门，而这些部门都是围绕着数据的基础设施。可以说，云极大程度的让数据，不管是结构化数据还是非结构化数据，都变得越来越多。

要实现数据的收集和处理并不容易，数据本身可能来自 SaaS API，来自日志，来自文件，以及各种形式的数据库，没有一个标准接口能将这些数据汇聚到一起。可以说，云的存在让数据孤岛这一问题变得更加严重。

这就是 Fivetran 想要解决的问题——致力于构建一个干净的抽象层，隐藏掉所有复杂性，让用户像使用电一样使用自己的数据，照亮自己业务的现状和前进方向。

作为一个 SaaS 服务，一方面连接企业的关键数据源，提取和处理所有数据，另一方面将其转储到一个数据仓库（如Snowflake，BigQuery 或 RedShift），以便在需要时进行 SQL 访问和进一步转换。如果数据是新的石油，那么 Fivetran 就是把它从源头送到炼油厂的管道。

计算资源和存储资源的成本趋势

Fivetran 能够重构数据整合赛道，是因为曾经强大的平衡已被打破：

在计算、存储和带宽极其稀缺和昂贵，以及数据的数量和种类有限的年代，通过工程师来解决 ETL 中存在的问题是可以被接受的。而如今，人力成本越来越贵，硬件的性能却迅速提升，成本极速下降。四十年内，存储成本已经从每千兆字节近 100 万美元骤降到几分钱。同样，自 20 世纪 70 年代以来，计算的成本已经缩小了数百万倍，互联网传输的成本已经下降了数千倍。

首先，计算、存储和互联网带宽的可负担性已经导致了云和基于云的 SaaS 服务的爆炸性增长，同时随着云计算的发展，数据的数量、种类和复杂性也随之增长。一个脆弱的、定制的管道，整合有限的数据量和颗粒度，已经不够了。简单的说，ETL 作为一种落后的生产力是注定要被扫到历史的垃圾堆里的。

其次，现代数据集成技术，让存储数据量和在仓库内执行查询频率受到的限制较少。计算、存储和互联网带宽的可负担性使得重新安排整合数据所需的工作流程成为现实。最重要的是，企业现在可以负担得起在数据仓库中存储未经转换的数据。

以上两点，是 Fivetran 能搅局古老的数据整合工具赛道的原因，云是背后很重要的推手，但同时本身硬件背后的进步也是不可小觑的。

老问题，在新的假设下，会有完全新的解法。

02.

Fivetran 的模式：

ELT + E 而不是传统的 ETL

这是 Fivetran 应对云时代挑战的解决方案，不是 ETL，也不仅仅是 ELT 而是 ELT + E。

ELT 是 ETL的一个现代替代方案。

以前，E 和 T 之所以被紧耦合在一起，是因为希望削减数据仓库中的数据量，利用好昂贵的硬件资源。但云原生的数据仓库，比如 Snowflake，从第一天起就拥有存储未经转换数据的能力，而且计算资源是弹性的，按需使用。在这种架构中，数据在提取后被立即加载到目的地，转换的步骤被移到工作流程的最后面。

在这种架构下，可以避免数据源发生变更，或下游业务方的分析需求发生变化，导致数据管道发生中断。这种简单和更强大的数据整合架构（ELT）能够更好的帮助企业提高业务敏捷性。

在 ELT 的架构设计下，数据被提取后，直接加载到目的地，即使数据转换的逻辑被分析师定期重写，企业仍然可以继续提取和加载数据。这些数据在到达目的地时只做了最小的改动，因此可以作为一个全面的、最新的来源，被进行分析，辅助洞察和决策。

更重要的是，提取（E）和加载（L）与转换（T）的解耦意味着提取（E）和加载（L）的输出物不再必须被定制。目的地可以直接用来自源头的数据进行填充，只需进行简单的清理和规范化，以确保数据质量、改善分析人员的体感，提升数据可分析性。再加上云计算的发展，这意味着提取（E）和加载（L）可以：

• 外包给外部公司降低成本

• 自动化使得代码可以被复用，降低开发成本和门槛

• 根据需要通过云计算扩大或缩小规模实现云原生中最重要的”弹性“

自动化的提取（E）和加载（L）有一个标准化的输出物，可以让使得数据模型的开发变得更加模板化或者标准化。这些模板化的分析产品可以跟转换（L）结合构建在数据仓库之上，这个产品在 Fivetran 的话语体系里是 Database building Tools，简称 dbt。

正因为有这样的工具，Fivetran 解决数据转换的策略也变为，无须在不同的数据源之间建立复杂的协调机制，也不需要通过拖-拉-拽界面来设计，可以使用 Python 等脚本语言编写。这也反应了 Fivetran 所相信的，SQL 是大势所趋，也应当是数据整合工具领域的标准语言。之所以这样相信基于两个观察：

• 大多数分析师可以用 SQL 来编写数据转换的逻辑

• SQL 是大多数分析产品的默认语言

同时 Fivetran 为了提高企业用户对于自己的产品的黏性，也不仅仅满足 ELT 的产品线，创造性的提出了 Embeded 的概念，可以将 Fivetran 的产品嵌入在客户的应用中，让客户只需关注交付给自己客户的业务需求，而不需担心数据管道的稳定性和数据分析的复杂性。

听起来可能很复杂，但其实这就是一个斩头去尾的逻辑，将数据整合和数据分析的复杂性全部掩盖：

让客户再也不用感知到数据消费、数据流转、数据生成的流水线中的复杂性，通过 Fivetran 可以一站式完成所有的需求。基于这样的思考，Fivetran 形成了自己 ELT + E 的产品线。

Fivetran 的产品线与特点

Fivetran 的产品主要分为三类：

• 「Extract/Load」解决数据连通问题

• 「Transform」解决数据变形问题

• 「Embed」解决发现数据价值的问题

第一类和第二类都是数据整合赛道非常标准的能力，前者可以通过连接器来解决数据在不同平台之间的互联互通；后者解决了数据分析师利用工具在云上数仓进行分析和协同开发数据模型的问题。第三类主要解决的是定制化 BI 工具和前端页面的重复建设的，通过 Fivetran 的产品可以掩盖数据链路中整合和分析的复杂性，终端用户只需看到分析报表和结果即可。

数据的抽取和加载

数据的抽取和加载，即「Extract/Load」，是一个数据整合工具最基本的素养。E 代表从企业内部各种各样的数据源中抽取数据，可以理解为水泵， L 则是经过城市水网（Fivetran 的 Connetor）之后，最终需要加载（L）到目的地，供各位城市的居住者来进行消费。

在传统的数据整合工具中，整合是说起来轻松，实际上需要有经验的工程师和分析师一起打造。分析师负责数据模型和分析报告，工程师负责搭建这样的城市水网，同时也需要保证水网中水压的稳定性和水网中水的洁净度，这里数据就是水。

和原有的数据整合工具比，Fivetran 简化了操作流程，产品简洁、敏捷和可靠等特点，还几乎支持云上所有的数据仓库，降低了分析师使用数据的门槛。不是特别懂代码的分析师也能轻松利用 Fivetran 搭建数据管道（a16z 的投资人在文章中说，连自己都能用！）整合企业内的多源数据，高效产出各式各样的分析、报表，进一步降低分析师对于开发者的依赖。

这意味着企业可以不用在像 ETL 时代一样雇佣一个由工程师构成的团队专门维护数据管道，这也对它在产品力上提出了新的要求：

• 要求是希望它在抽取数据的时候对源端的系统尽量不要造成影响

• 自动感知上游的数据变化，并相应的做出调整

• 数据能够百分百的保证同步到下游

• 还能能随时随地的扩展

• 有着极强的加载速度

• 云中立，可以支持高效的跨云复制

• 对数据整合工具有 100% 的访问权限

• 价格也能做到和整合的数据规模解耦

这些，Fivetran 都可以做到，某种意义上 Fivetran 产品就是为了弹性而生，为分析师而打造！

除了本身的产品力，还有严格的数据隐私和合规需求，这也是云时代每家数据 SaaS 公司都要过的难关，Fivetran 除了支持不同地区的数据隐私合规政策（支持 SOC 2 和 GDPR）以外，还支持动态和静态加密，确保数据传输过程中的安全性。从 Fivetran 诞生的第一天起就开始考虑数据隐私及其合规的需求。最有意思的是，如果用户还不放心，Fivetran 的产品支持每次同步之后删除数据。

给数据整个形的 Transform

Fivetran 转换的主要功能依托一个叫 data build tool 的工具，简称 dbt。dbt 是一个转换过程的工作流程，让团队能够按照软件工程的最佳实践，如模块化、可移植性、CI/CD 和文档，快速和协作地部署分析代码。dbt 可以让任何懂得 SQL 的人都可以建立生产级的数据管道。

dbt 是一个开源软件，使终端用户可以使用简单的SQL语句在目的地进行复杂的数据转换。数据模型的逻辑通常是复杂的，特制的，难以维护的，但是通过使用 dbt，你可以：

• 编写和测试 SQL 转换

• 对转换逻辑使用版本控制，追踪变化

• 创建和分享关于你的 dbt 转换的文档

• 查看数据脉络图

此外，dbt 支持命令行（在操作系统中，提示进行命令输入的一种工作提示符）界面和云上 SaaS 服务两种模式，可以轻松的帮客户实现：

更快的开发 用简单的 SQL SELECT 语句代替繁琐的 DDL/DML，推断依赖关系，建立表和视图，并按顺序运行模型。在云计算集成开发环境中，用宏、引用语句和自动完成命令来编写代码。

从相同的假设出发开展工作 dbt 的预包装和定制测试帮助开发人员为数据合作者创建一个经过验证的假设的 "纸轨"。自动生成的依赖关系图和动态数据字典促进了数据消费者的信任和透明度。

充满信心地进行部署 通过应用内的调度、日志和警报，将可观察性纳入转换工作流程。分支上的保护策略确保数据在受监管的过程中移动，包括每次 CI 运行产生的开发、阶段和生产环境。

把数据 Embed 在应用里

越来越多的客户都愿意把数据上传到 Snowflake 这样的云上数仓进行分析。将公司拥有的所有数据通过 Fivetran 提供的标准产品搬迁到云上数仓的同时，仍需要为定制化的业务需求和分析报告准备好 BI 工具和数仓的资源。

标准的 Fivetran 的产品只是解决了数据管道的稳定性和易用性问题，遗留的问题是，每一次通过 Fivetran 搭建数据同步链路仍然还有一部分工作是需要重复建设的。毕竟，客户总有定制化的报表需求，对于这些不同的需求，就需要使用不同规格的数仓资源和不同的 BI 工具来实现。

这一问题可以通过将 Fivetran 的产品耦合在搭建的应用内部来解决。使用「Embed」后，客户的数据将会自动被搬迁到云上数仓中，自动的生成分析报告，省去搭建 BI 工具和数仓的时间，这些时间可以被用来专注于应用开发，给企业的客户带来极致的数据洞察力。

刚才的描述可能过于抽象，Fivetran 的官网上举了一个 Crossmedia 公司的例子。这是一家全球性的独立媒体机构，总部设在纽约市。Crossmedia 没有被某家大型公司控股，至今保持独立运营，这也意味着 Crossmedia 没有很强的工程师团队，不了解如何透明的处理数据，以及如何解决数据分析和整合等诸多技术挑战。

这些挑战都在使用 Fivetran 的产品之后得到了缓解。通过使用 Fivetran 的产品，Crossmedia 无需雇佣整个工程师团队 24 小时维护数据管道，而是通过使用 Fivetran 的服务及时整合并分析数据，Fivetran 使得 Crossmedia 能够更加专注在客户数据的高级分析上而不是担心数据管道本身的稳定性上。

此外，通过把 Fivetran 嵌入到自己的应用中，Crossmedia 成功的将为客户生成报告的时间从一整天缩短到几分钟，这是超过几千倍的优化！此外，Crossmedia 不需要像过去一样耗费几周的时间为客户构建集中的营销仓库，只需要花费几天。从客户成功的角度来看，由 Fivetran 提供 ELT + E 的产品，100% 地改变了现状，持续的帮助 Crossmedia 提升效率，Crossmedia 为客户开发数据产品的速度已经成倍增长。

这就是 Embed 的魅力！解决了企业更好的发现数据的价值，Fivetran 也因为 「Embed」得以将复杂的云上数仓和 BI 工具创造出的复杂性都隐藏在分析师就可以使用的 Fivetran 的产品中。

03.

发展策略：云上数据库的连接器

Fivetran 连通的不仅仅是云上的 SaaS 服务，还有各种的云上数据库，以及这些 SaaS 服务衍生出来的事件、文件、和 Functions（主要是海外三朵云的 Lambda 架构）。

根据 DB-Engine 的统计，目前跟数据相关的产品已超过 300 家，这个数字在未来只会增加，不会减少。每增加一种数据平台的类型，如同在现实世界中，增加一座城市一样，就需要将这座城市和原本的高速路网相连通。

每多一种连通，就意味着要增加一种连接器。Fivetran 目前支持超过 150 种数据源，这是 Fivetran 的护城河，也是在数据整合赛道中无与伦比的竞争优势。

无论是数据库还是云上的 SaaS 服务，Fivetran 的产品都能支持，这是为了未来的数据形态而打造的数据复制技术。某种意义上，Fivetran 的产品使得的数据整合这件事情看起来毫不费力，跟传统数据整合工具使用中体现出来的配置复杂和运行不稳定，完全不一样。

而且，Fivetran 还通过独特的发展策略来巩固自己的产品优势。

不仅数据整合，更发现数据的价值

如果只做数据管道，价值不够高，客户的粘性也不会很强。

Fivetran 能够真正帮企业做好数据分析。在官网上，Fivetran 把企业购买服务的场景分为两种，一种是分析自己的内部数据，一种是给外部客户提供数据分析服务。这里我们主要讨论后者。

当一个企业在服务自己客户时，需要在云上 SaaS 服务间搭建数据同步管道，将散落在不同平台上的数据，归拢至一处（可能是 Snowflake 也可以是 Bigquery）。同时，企业还需要搭建 BI 工具来给自己的客户提供分析结果的展示，这些步骤需要很强的技术团队才能搞定，中小公司很难完成。

但如果使用 Fivetran Embed 这样的服务，企业就不用担心数据归拢和治理的问题，可以更专注在分析和报告本身。

简单来说，通过把 Fivetran 的产品植入自己的业务中，可以降低客户消费数据时遇到的复杂性。在没有 Fivetran Embed 这样的产品之前，企业虽然也可能使用 Fivetran 的数据管道这样的产品能力，但是还需要企业自己来对数仓中的数据进行消费并搭建 BI 工具来进行展示。有了 Fivetran Embed 这样的产品之后，企业可以选择直接将其植入到自己的业务中，只关心最终的数据展示而不需关心数据从哪儿来，如何分析，如何展示等等一系列复杂的问题。

Fivetran 在其官网中也总结了适用于 Embed 的四种使用场景：

第一种是将你的客户数据连接到你的应用程序，构建生成答案的应用程序，而不再仅仅局限于数据管道；

第二种是将数据转化为对客户的洞察力，把时间花在你的客户实际看到的工作上，不要再把宝贵的时间花在所有的数据整合和数据管道的维护上，而是把它花在建立报告和分析上，让这些报告和分析持续的为你的客户提供价值；

第三种是消除凭证管理风险，获取客户的敏感数据是很尴尬的，而维持与这些数据源的连接是一件永无止境的苦差事。由 Fivetran 的连接卡（Connect Card）技术提供支持，可以不需要再通过邮件传递敏感的用户登录信息，允许现有客户和潜在客户将他们的数据直接连接到你的应用程序，而无需与你分享他们的敏感登录信息；

第四种是通过 REST API 来规模化和可编程式的接管更多客户的数据，提升数据连接和交付的效率。

这一方面增加了使用 Fivetran 的黏性，一方面增加了 Fivetran 产品本身的价值，最重要的是也让专业的人做专业的事，整体的提高了围绕数据上下游的行业的生成效率。

边际递减的定价策略

Fivetran 的产品定价分为 4 个等级，分别是 Starter、Standard、Enterprise、Business Critical，前三种都是依据在 Fivetran 平台上的用量算出一个信用（Credit），进而按照信用（Credit）的多寡来进行收费，最后一种可能需要定制服务，所以没有明码标价。

从 Starter 到 Business Critical，每上升一个等级，除了拥有更多的数据库和连接器支持以外，在安全、扩展性、还有支持的待遇上都有越来越多的提升，具体可以在 Fivetan 的官网上详细了解。

Fivetran 的定价策略跟云上 SaaS 服务接近：只为你所使用的付费。但 Fivetan 设置了一种非常有意思的计费方式：

信用额度与企业的使用 Fivetran 产品中的每月活动行数（Monthly Active Rows），简称 MAR,对应。企业客户使用的 MAR 越多，你消耗的信用额度就越少。

这种定价策略使得单个用户在 Fivetran 的费用增长曲线更像是一个 x^{1/2} 的函数，这种方式使得客户的花费的金额的边际增长越来越小。如果不采取这种方式，客户迟早有一天会无法承受在某种技术上的开支。这不免让人想起 Twilio 和 Uber 之间的故事，以及 Oracle 要在原本的收费模式以外专门设置了一个 ULA 许可，甚至还有一个 Software Investment Advisor 部门专门负责帮助各大公司的 CIO，分析如何通过 ULA 更合理地使用 Oracle 的授权。Fivetran 这样的定价策略可以有效避免大客户的流失，增加客户黏性和忠诚度。

举个例子，假设 A 和 B 公司都有 1000 美金的预算，如果 A 公司购买了 Enterprise，版本获得了 500 信用，B 公司选择购买了 Started 版本，获得了 1000 信用。但由于 A 公司的 MAR 大于 B 公司的 MAR，最终可能 A 公司消耗信用的速度要小于 B 公司消耗信用的速度，这背后的原因就是消耗信用的速度是根据的 MAR 来决定的，MAR 遇大，信用消耗速度越小。

尚不清楚 Fivetran 的 MAR 和 信用消耗速度的对应关系，但是可以做一个大胆的假设。A 公司有 2000 MAR，对应每小时 10 信用，B 公司 有 1000 MAR，对应每小时消耗 18 信用。通过简单的计算便可知道，A 公司可以使用 50 小时的 Fivetran 的服务，而 B 公司可以使用大约 55 小时的 Fivetran 的服务。虽然 B 公司使用的时间稍长，但是不同级别的服务拥有较大的差异。通过这样的定价策略，Fivetran 可以在用量和客户花费间营造一种平衡，进一步的增加了客户对于 Fivetran 产品的黏性。

补完最后一块拼图：并购 HVR

按照 Gartner 的定义，在数据整合工具赛道，有四种关键能力：数据工程、云迁移、业务数据整合、以及面向未来的数据编织，这四个维度也是 Gartner 用来衡量数据整合工具领域供应商在魔力象限里的地位的标尺，这四种关键能力的详细介绍如下：

数据工程

通过遵循定义的架构模式、工具和方法，建立、管理和操作数据管道，以支持各种数据和分析需求（如逻辑数据仓库和数据科学）。这些需求可能包括提取、转换、加载/提取、加载/转换或（ETL/ELT）或变动数据捕获（CDC）。

云迁移

将数据和分析工作负载迁移到公有云并使陈旧的技术和资源的利用方式可以现代化，通常涉及一个横跨企业内部私有云和一个或多个云生态系统的新型架构。

业务数据整合

支持业务/交易数据整合使用，如关键任务数据管理、企业间数据获取和共享（包括在需要时创建数据中心进行整合的能力）。这也包括整合、巩固和同步与关键业务流程相关的数据，并支持数据治理举措。

数据编织

通过利用主动元数据、语义和机器学习（ML）能力，使人们能够更快地访问分布式架构中的可信数据。这是一个非常新兴的设计，市场上还没有真正意义上的技术供应商；数据编织在市场上还不是一个常见的使用场景，这是一个面向未来的关键能力，旨在将数据和人在时空中进行准确的匹配，即合适的地点、合适的时间，对的人用到对的数据。

Fivetran 的产品特点是完全基于云上的 SaaS 服务，在一个高可用平台架构的基础上提供一个自动化、能够保证 99.9% 可用时间的、百分百保证数据不丢的端到端的数据管道，在发展不到 10 年的时间里已经积累了超过 2400 个客户在云端使用这样的数据整合服务。Fivetran 产品的关键能力主要有:

• 在满足接近实时同步的要求下，可通过物理模式将数据单向的从目的地搬到云上数据的数据仓库。它不支持双向的比较型同步，也不能用于任何企业私有云环境搭建的数据存储。

• 在增强的数据整合能力方面很有竞争力，例如自动感知上游数据结构的变化，并相应改动数据同步的逻辑，同时也能做到在灾难做到自动恢复。然而，它没有通过数据的语义抽象充分支持数据的虚拟化，也没有面向消息和数据的移动的封装，缺乏数据编织的能力。

• 缺乏对数据治理的支持能力，如对集成数据、元数据共享和数据质量补救执行政策和合规规则的能力。

相较于业务数据整合和数据编织，Fivetran 在云迁移和数据工程的使用场景方面相对较强。在云迁移这种关键能力，Fivetran 能够将数据和分析工作负载迁移到公有云并使之现代化。这通常涉及一个跨越企业内部和一个或多个云生态系统的架构。Snowflake、Google BigQuery 和 Amazon Redshift 是其最受欢迎的数据仓库平台。在数据工程这种关键能力上，Fivetran 提供内置的高级转换能力，如将完整的数据复制到一个经过策划和记录的模式中，并提供预包装的 dbt（dbt 是一个用于数据构建工具）财务包，可以在几分钟内产生资产负债表、利润表、总账。在业务数据整合关键能力上，Fivetran 在业务数据整合所需的各种关键能力方面得分最低，如数据治理支持、整合可移植性和API服务。它不太适合用于支持数据治理措施的关键业务流程整合，如主数据管理（MDM）。

HVR 为基于日志的 CDC 提供同名的数据集成产品。该供应商的这套产品的客户群包括 450 多个组织。HVR 关键能力有：

• 支持数据移动拓扑结构。它支持数据的单向和双向移动，用于数据整合（单一目标）或数据广播（多个目标），以及级联复制，用于分发准备好的数据。对于主动/被动配置，支持数据的多向移动。

• 支持在基于 CDC 的数据复制基础上进行复杂的数据转换。例如，它支持自动数据类型映射和转换、行级转换、缺失值的存根、异常值的修复和字符集转换。如果需要，可以使用软件开发工具包（SDK）来调用外部数据转换逻辑，由 HVR 完成协调工作。

• 在数据治理支持方面需要做更多工作。与第三方工具的数据治理集成需要用户编写自定义 SQL 代码。同样，HVR 也没有自己的数据目录来获取元数据，而是依赖于与其他供应商的数据字典的集成。

与数据编织的关键能力相比，HVR 在数据工程和业务数据整合用例中相对更强。在数据工程这种关键能力上，HVR 通常用于将数据从企业内部的关系型数据库复制到分析型云数据存储，如 Snowflake、AWS Redshift 和 Google BigQuery。比较源和目标数据模型并自动纠正任何差异的能力使数据工程师能够更容易地监测和维护数据管道。在业务数据整合关键能力上，HVR 中心组件使客户能够将 HVR 作为一个数据中心来实施。HVR 有能力支持大批量的数据实时复制，为交易系统提供动力。在数据编织关键能力上，HVR 不提供企业知识图谱平台，也不支持主动元数据采集。这限制了 HVR 在数据编织用例中的适用性。

如果说 Fivetran 是从云上起家，只做云上 SaaS 服务和云上数仓间的数据同步；那么 HVR 就是专做云下，只做异构数据库之间的数据同步，拥有 15 年历史的 HVR 被比自己小了 6 年的 Fivetran 并购。Fivetran 和 HVR 的并购算是强强联合，双方都补齐了自己最弱的那块短板。

04.

领导者面对的挑战

身为这个赛道的leader，Fivetran 面对的是波谲云诡的挑战。

同为初创企业的挑战

Airbyte

这是一家由 John Lafleur 和 Michel Tricot 在2020 年的创立的一家非常年轻的初创公司， 在不到一年的时间内连续融资 2 次，累计融资 3000 多万美金，主要投资方有 MongoDB CEO Dev Ittycheria 和 Y Combinator，领投方为 Benchmark。Benchmark 是一家非常老牌的投资公司，在 1997 年投资 eBay 670 万美金，占股 22%；14 年后，Benchmark 1100 万美元投资 Uber， 占股11 % 。相信 Airbyte 一定有非常特别和迷人的因素，才使得这些重量级玩家纷纷加注。

Airbyte 的产品主要的使用场景跟 Fivetran 非常类似，是 ELT + E 的场景，关注数据的互联互通，和最终的数据交付。（这篇文章开始于2021年10月中旬），那时 Airbyte 还仅认为自己是一个 EL 公司，只负责帮助客户完成数据的抽取和加载，短短一个月时间，Airbyte 就完成了战略转型。不得不吐槽一下，很多 Research 的工作就此报废，也可以看出敏捷性是这个时代最为追求的东西。）

回头来讲，Airbyte 和 Fivetran 唯一的区别是：产品是否开源。Airbyte 的 CEO 也是联合创始人之一，Mike 在接受 TechCrunch 的时候说，“这才是正确的打开方式，因为如果社区有人使用你的连接器遇到了问题的时候，问题的修复本身是给全社区带来收益的”。也像目前另外一家 Infra 领域的公司，PingCAP CEO，刘奇在 Dev Con 上指出的那样，”真实的场景才是最好的架构师“。开源对于 Infra 公司的好处是能够占领开发者的心智，带来足够多的 Adoption，但这里需要指出的是没有任何一种破局之路是完美的，开源和商业化之间，也会存在一定程度上的矛盾。

正因为All in 开源，Airbyte 目前已经有超过 7000+ 家，每月有 1000 亿行的数据正在使用 airbyte 的产品，同时开源社区也人才济济，汇集了超过 500 多位 contributor 一同参与到 Airbyte 的产品研发之中。现在 Airbyte 也正在积极布局自己的 GTM 团队，正在全方位的招聘解决方案、销售、产品经理、市场经理等职位。笔者个人也特别喜欢 GTM 这个词汇，因为本身这个组织在创业公司商业化的初期真的不需要有部门墙，也不需要把每个工种的职责梳理的过于清晰，如果那样反而不利于 GTM 团队的敏捷性。

Tapdata

Tapdata 是成立于 2019 年末的中国创业公司，成立不到两年内的时间，已经获得以五源资本领投在内的连续 3 轮融资，创始人是唐建法，曾经担任 MongoDB 大中华区首席架构师也是 MongoDB 中文社区主席，有十多年的海外工作经验。

Tapdata 的核心产品是为数据业务提供一个实时数据服务平台（Real Time DaaS），包括基于日志的实时同步管道，低代码流式数据开发和数据API服务三大能力模块。相较于 FiveTran 是从 ETL/ELT 开始，专注为数仓（Snowflake/Redshift) 以批量方式供数，Tapdata 似乎更加关注价值更高的实时数据服务，实时数据管道本身的搭建反而看起来像是顺带的。

在市场获客上，Tapdata 没有选择开源而是选择了免费的策略。从今年开始布局云版，通过提供一个永久免费版本的方式来获得云上客户的使用。一方面可以通过免费使用来获取客户，一方面通过企业版和免费版的功能特性的区分度来牵引客气进行高级功能的付费。虽然不是开源，但是在 Adoption 这个维度上可能会比开源效果更好，但开源除了 Adoption 以外其实还有社区的概念，可以营造共创、在一起的感觉，这一点是免费云版无法提供的。

在海外市场的拓展上，Tapdata 似乎跟现在中国所有的基础架构创业公司都会遇到的问题一样：如何解决海外市场的 awareness 和本地优质资源的部署。这一点创始人在海外的工作经历、MongoDB的社区背景有可能会有些帮助。另外 Tapdata 自带主数据服务能力，这个目前海外还没有成熟的竞品，这也是和目前在数据整合赛道中和其他友商的竞争差异。让我们拭目以待，看看 Tapdata 如何在海外跟 Fivetran 和 Airbyte 这样在本地拥有资源的公司如何进行竞争。

古老、新兴又充满竞争的赛道

说这个赛道古老，因为确实历史悠久！说它新兴，确实因为硬件成本的降低，让云成为了主流的组织资源的方式以后，对这个赛道又提出了新的挑战。这个赛道的竞争壁垒还是在于连接器的多少，护城河较低，可以有很多玩家参与其中，但是它作为产品的竞争力而言还是体现在连接器的多寡、产品的稳定性等方面。比如，Airbyte 也积极响应这种变化，从一开始的只做 ELT 到现在的跟随 Fivetran 的脚步也增加了 E （植入）的功能通过增加数据在后端的价值，提升客户黏性。这种战略上的跟随也预示着未来的竞争会越来越激烈。

随着云上 SaaS 公司越来愈多，数据的互联互通成为刚需，不知道数据整合赛道会不会也像分布式数据库赛道一样，出现国外两家（Cockroach、Yugabyte），国内一家（PingCAP）的情况。

以 Fivetran 为例，通过两次，间隔不到半年的收购，Fivetran 持续在数据同步的赛道中构建自己的护城河。毕竟兼容的数据库越来越多，兼容的 SaaS 服务越来越多，既能增加客户黏性，又能增加和竞品的区分度，说到底，数据整合这个赛道还是非常古老的，有太多的竞争对手了。Fivetran 自身在非云上 SaaS 的关键能力上有明显短板，通过并购可以起到 1+1 大于 2 的作用。

除此之外，Fivetran 还积极拓宽自身业务的边界，创造性的将原本 ETL 的数据整合赛道，从变成了 ELT+E 赛道，数据不在传输过程中转换而在这之后进行转换，提高数据管道的稳定性，提升数据链路的实时性，同时可以随时随地拉起一个数据服务平台可支撑 Fivetran 服务的客户的客户的业务需求。

看起来有点像套娃，但实际上不是，就是更好的让 Fivetran 的客户专注于服务它的客户，把脏活、累活、苦活都留给 Fivetran。但即使这一个变化的赛道也有了一些新的竞争对手，Fivetran 开局不错同时也通过并购增加了自己的竞争力，但在实现“像用电一样使用数据”的愿景的道路上还有很多的变量和风险。

Reference

https://fivetran.com/pricing

https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwi_3JzVxLz0AhWP63MBHXvsC7MQFnoECAYQAQ&url=https%3A%2F%2Ffivetran.com%2Fblog%2Fetl-vs-elt&usg=AOvVaw1JWLlBACmCIwN2Ct8_yYEN

https://a16z.com/2019/09/24/fivetran/

https://aithority.com/security/fivetran-completes-acquisition-of-hvr

https://www.crunchbase.com/organizatio

https://www.crunchbase.com/organization/fivetran/company_financials

关于「海外独角兽」

「海外独角兽」是一个优质内容公共平台，每周两次，我们在这里深度分享科技大航海时代的顶级创新公司。偶尔也会分享让商业世界变得更好的新理念、新技术、新思考。

「海外独角兽」背后的支持团队包括科技媒体从业者，顶级机构投资人，游戏、crypto、生物科技领域的创业者。我们相信信息筛选的价值，也相信无论投资还是创业，都需要对未来趋势有清醒的认识和把握。

如果你想参与优质内容的推荐或翻译，欢迎加入我们的内容共创群；如果你是投资人或LP，对全球领先公司感兴趣，也欢迎找我们碰撞思想。主理人微信：

  延伸阅读

HashiCorp：企业上云的桥梁，云计算领域的 Shopify

分拆 Office 数十年后，40亿美金的 ClickUp 重新整合生产力工具

Zapier：“API 的 API”，无代码的超级聚合器

Stripe：从7行代码到千亿美金的互联网基础设施